Here is the usual "release notes" describing the changes from the previous Mops version, so that those already using it don't have to wade through all the documentation (or have to read right through the huge manual!!!).
This release just adds one major new feature—a better way of doing system calls.
The new way will work unchanged on the future native PowerPC version of Mops—in fact some of its details have been determined by what we're going to have to do on the PowerPC. The new way should also be a lot easier to use, since it takes care of the different parameter lengths for you.
Note that the old way of doing system calls is still supported, so your existing code won't break, but it *won't* be supported on the native PowerPC version when it's eventually released.
Since I haven't updated the Demo yet, I won't be releasing a new manual at this time, but just describing the new feature here. Because there are so many system calls, I haven't been able to test the new feature exhaustively. But once it's been in use for a while, if everyone's happy with it, I'll probably revise the Demo and release a new manual.
Calling the System—SYSCALL
Here's an example of a word to set the cursor, done the old way and the new way.
The old way:
: set_my_curs { curs# -- }
0 \ space for returned result
curs# makeint \ cursor ID # is 16 bits
call GetCursor \ Returns handle to cursor
@ \ needs to be a pointer for SetCursor
call SetCursor
;
The new way:
syscall GetCursor \ Note: these are CASE-SENSITIVE!
syscall SetCursor
: set_my_curs { curs# -- }
curs# GetCursor \ Returns handle to cursor
@ \ needs to be a pointer for SetCursor
SetCursor
;
Note the following points:
1. You have to "pre-declare" any system call you're going to use, outside any definition, and before any definition in which you do the call. It doesn't matter if you use SYSCALL several times over for the one call—in different source files, say—subsequent ones will be ignored. But we are going to need to do this on the PowerPC, because of the way that system call names get bound to actual addresses, so we'll start doing it now.
2. The names following SYSCALL are case-sensitive—again the PowerPC way of doing things forces this on us (on the PowerPC, the binding of system call names to addresses is a case-sensitive operation). So for example, if we had put
syscall getcursor
above, we would have copped a compile-time error message telling us that Mops couldn't find the name.
3. The returned result is simply pushed on to the stack—you don't have to push a zero there at the beginning to make room.
4. makeint is no longer necessary. Likewise the other words needed for manipulating 16-bit quantities on the stack—word0 and pack. You simply push the parameters in order, and don't worry about the lengths. Mops reads information bytes stored with the SYSCALL declaration in the dictionary, figures things out and adjusts the stack before executing the calling sequence. (On the PowerPC, the lengths will be different—generally a fixed size of 32 bits. So we really had to do something about this.)
SYSCALL uses the Universal Headers
As many of you no doubt know, for the last couple of years Apple has been releasing updates to its API in the form of "Universal Headers" (for C) and "Universal Interfaces" (for Pascal). (API stands for "Application Program Interface", and covers all System calls, the data structures which participate in those calls, and system-defined constants.)
In Mops, we have always provided a way of accessing the Apple API via the Tools module, which provided the words CALL, KONST and GLOB. The Tools module gets its API information from some files which I obtained around 1991, so we are quite a bit out of date now.
Last year I collaborated with Xan Gregg who was developing Power MacForth for Creative Solutions, and I wrote a program to parse the Universal Headers and produce output files which would be suitable for reading by both MacForth and Mops. SYSCALL is implemented by a new module, CallsMod, which when it is compiled reads in a file called "xcalls" which my program generates (this file should be in the Module Source folder). All the API information we need is read out of this file and built into the dictionary of CallsMod when it compiles.
This means that we are now up to date with the latest Apple information, and it will be easy to keep up to date in future. Whenever the Universal Headers are revised, I can rerun my program and generate a new xcalls file, which I can make available for downloading. You can then update CallsMod simply by recompiling it, via
compile: callsMod
in the usual way.
CallsMod also implements KONST, which functions exactly as it did before. But CallsMod does not implement GLOB. This word is still available as it was, via the old Tools module, but it now definitely isn't a good idea to refer directly to low memory globals. The Universal Headers (and therefore SYSCALL) provide accessor functions to do what you used to do by directly accessing the globals. But most importantly, in future systems such as Copland, the globals will probably not be there any more!
I know there are still a number of places in the Mops system where I access globals directly, but I'll be trying to get rid of these progressively.
Time and space
The Universal Headers are large, so the xcalls file turns out to be 1.1 megabytes long. We achievesome savings by encoding the information stored in the dictionary in CallsMod, but CallsMod still weighs in at nearly 600K. This means that there must be this much heap space available when you use SYSCALL in Mops. I have therefore increased the default partition size for Mops to 1600K, with a minimum of 1400K. If you reduce it below this, you won't be able to use SYSCALL.
But note, this increased memory footprint won't apply to installed applications, since these won't contain CallsMod (unless you need it because you do compiling at run time in installed apps—in this unusual situation, you will need the memory space).
CallsMod also takes quite a while to compile—about 10 minutes on a Mac IIsi. If you have a slower Mac, take a long coffee break. CallsMod will be compiled when you compile up the Mops system for the first time, so this will be an even longer process than it was before. Sorry, but normally you'll only have to do it once per new Mops release. Such is the price of progress.
You may conclude that once you've compiled up Mops 2.7, you can trash the xcalls file. This is right, but probably not a good idea in case you need to recompile the Mops system at a later date for any reason (such as to incorporate bug fixes).
(Bugs? What bugs?)
Thoughts on the future
This section always appears in my release notes, and is for thoughts on the future development of Mops. The big commercial outfits don't "speculate on unnanounced products", but not only do I do it, I welcome feedback!
The main thing from now on will be to continue work on the native PowerPC version. I hope to get this done in the first half of next year (1996). Progress is going well, but it's a big job.
Every now and then I chew over some wild ideas like persistent objects and garbage collection, but the native PowerPC version is going to come before everything else
The PowerPC also opens up some other interesting questions—noteably, the eventual change to a 64-bit system. The first 64-bit PowerPC chips may arrive in 1997, but will probably take a while longer before they're available in Macs that the rest of us can afford. Anyway, I would like to be able to adapt Mops to this new environment, especially as the Forth standard now avoids any particular word-length dependencies.
Under a 64-bit implementation an address will become 64 bits. The ANSI standard specifies that a stack cell must be able to hold an address, so a stack cell will have to become 64 bits as well. @ and ! refer to stack cell sized data, so they will become 64 bit operations. After some discussion on comp.lang.forth about this, the best proposal for operations of other lengths are 8@, 16@, 32@ etc. It's far too confusing to refer to "halfwords" or "longwords" or whatever. Let's call a spade a shovel and be done with it. C@ will remain the same, and thus be an alias for 8@.
For objects, ints and vars should probably remain as they are, with something new for 64-bit operands. Do people often store addresses in vars? Is this a problem? We have an Addr class, so I hope vars haven't been used for addresses. If they have, var would have to become 64 bits long and we'd need something new for 32 bits. But I'd prefer to leave var as 32 bits and have something new for 64. That's what I'll do unless I get a lot of objections.
In any case, 32-bit machines will be with us for a very long time yet, so 64-bit compilation will have to be an option. It would be nice if code can be compiled and run successfully under either option without changes, so this is what I'll aim at. So try to write your code without too many cell-size dependencies.
As always, I wish you every success with Mops. I don't mind getting email, but please read the FAQ first (see below), and also consider posting to comp.lang.forth.mac. If it looks like a Mops bug then email is probably best, but if it's a general question about getting started or use of the Mac Toolbox, try the group first. There are certainly people there who know more than me about specific Toolbox areas, especially comms and graphics. But feel free to email me with compliments at any time!! :-)
Internet and Web info for Mops
If you have internet access (if you don't, you probably soon will!), you'll find Mops discussion in the group comp.lang.forth.mac. Feel free to dive in there. Also note that I post a FAQ (frequently asked questions) list there every month or so.
There's a Mops web page at <URL:http://www.netaxs.com/~jayfar/mops.html>.This has links to the FAQ, the latest Mops version, and other Mops-related goodies.
